Partimos de un escenario en el que tenemos un repositorio de GitHub con 3 ramas:
Para reproducir la situación tenemos que realizar los siguientes pasos:
- Creamos un archivo nuevo en main y hacemos commit
- Nos movemos a staging y hacemos merge de main, despues hacemos push hacia el repositorio
- Nos movemos a develop y hacemos merge de main
- Borramos el archivo en la rama develop hacemos commit y push
- Desde el Github hacemos una PR desde develop a main y la mergeamos
- En la consola nos movemos a staging y hacemos pull del repositorio para traernos los cambios de la PR
- Ahora hacemos un git reset --hard en staging al penultimo commit que se muestra en el git log. <---EN ESTE PASO ES DONDE SE GENERA LA ANOMALIA
- Ahora repetimos la secuencia de comandos desde main:
- Creamos un archivo nuevo en main y hacemos commit
- Nos movemos a staging y hacemos merge de main, despues hacemos push hacia el repositorio
- Nos movemos a develop y hacemos merge de main
- Borramos el archivo en la rama develop hacemos commit y push
- Llegados a este punto si hacemos una PR de develop a staging es cuando se produce la anomalía y el merge que se hace desde Github no borra el archivo, pero si lo hacemos desde la propia consola si que lo borra.
Si revisamos el log vemos lo siguiente:
En el último commit (flecha azul) se ve que el archivo figura como añadido
Si miramos los dos commits que participan en el merge (flechas rojas), vemos que en uno el archivo está añadido y en el otro el archivo está borrado, y si miramos las fechas (lineas verdes) vemos que el borrado es mas reciente, por lo tanto debería de prevalecer el commit del borrado sobre el otro
Si volvemos a la situación antes de hacer la PR de develop a staging y hacemos un merge directamente desde la consola (sin hacer PR en GitHub) vemos lo siguiente:
El archivo se borra al hacer el merge, si miramos los logs vemos lo siguiente:
Como podemos ver la situación es exactamente la misma, pero el resultado es diferente, en este caso el archivo acaba borrandose.
Conclusión
Al final es cierto que GitHub se comporta de una manera anómala, pero tambien es porque se ha forzado el reset de una rama a un commit que no debería.
Todo este problema aparecio en el proyecto de Angular de la PostAcademy, no sé si en ese proyecto se produjo exactamente de la misma manera, pero algun comportamiento anómalo tuvo que haber para que las ramas llegasen a esa situación